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Abstract 



Developing extensible, robust, and efficient distributed ap- 
plications cs a complex task. In order to help alleviate this 
complexity, we have developed the ADAPTIVE Service ex- 
ecutive (ASX J framework. ASX is an object-oriented frame- 
work composed of automated tools and reusable C+ + com- 
ponents that simplify the development, configuration, and re- 
configuration of distributed applications in a heterogeneous 
environment. These applications may be configured dynam- 
ically to contain multiple network services that execute con- 
currently in one or more processes or threads. Components 
in the ASX framework have been ported to UNIX and Win- 
dows NT and are currently being used in a number of large- 
scale production distributed systems. This paper describes 
our experience gained using the ASX framework to buiid a 
highly modular, reusable, and extensible software architec- 
ture for a family of distributed system management applica- 
tions. 



1 Introduction 

The demand for extensible, robust, and efficient distributed 
systems is increasing dramatically in research and commer- 
cial environments. Although distributing application ser- 
vices among a set of autonomous hosts offers many poten- 
tial benents. developing distributed systems is more complex 
than developing non-distributed systems. A significant por- 
tion of this complexity arises from limitations with conven- 
tional tools and design techniques used to develop distributed 
application software. In particular, network programming 
tools (such as sockets, named pipes, and RPC) available in 
contemporary operating systems (such as UNIX. Windows 
NT. and OS/2) lack type-safe, portable, re-entrant, and ex- 
tensible programming interfaces. For example, both sockets 
and named pipes identify endpoints of communication via 
weakly-typed Vo descriptors. The use of these descriptors 
increases the potential for subtle run-time errors. Another 
major source of complexity stems from the widespread use of 
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algorithmic design techniques to develop distributed appli- 
cation software [1]. Many distributed systems are developed 
using algorithmic design techniques that result in monolithic, 
non-extensible software architectures [2]. 

Object-oriented frameworks help to alleviate the complex- 
ity associated with developing distributed applicauon soft- 
ware. A framework is an integrated collecaon of software 
components that collaborate to produce a reusable architec- 
ture Vor a family of related applications [3]. Object-oriented 
frameworks are becoming increasingly popular as a means tc 
simplify and automate the development and configuration oi 
complex applications in domains such as graphical user in- 
terfaces [4], databases (5], operating system kernels [6], anc 
communicauon subsystems (7. 2). 

The components in a framework typically include classe: 
(such as message managers and timer-based event managers 
and connection maps [8]), class hierarchies (such as an in 
hentance lattice of mechanisms for local and remote inter 
process communicauon [9]). class categories (such as a f am 
ily of concurrency mechanisms [2]). and objects (such as a 
event demultiplexer [10]). By emphasizing the integrauoi 
and collaboration of application-specific and applicauon 
independent components, frameworks enable larger-scaJ 
reuse of software, compared to reusing individual classes an 
stand-alone functions. 

To illustrate how object-oriented frameworks are being ac 
plied successfully in pracuce. this paper examines the fc< 
tures, structure, and usage of the .ADAPTIVE Service eXet 
uuve (ASX). We developed the ASX framework to provic 
an integrated collecuon of reusable, object-oriented nctwor 
software components. These components simplify the deve 
opment of distributed applications by enhancing the modi 
laxity, extensibility, reusabiliry. and portability of softwaj 
that utilizes operating system (OS) concurrency, explicit d; 
namic linking, interprocess communication (IPC), and 1/ 
demultiplexing mechanisms. 

In addition to describing the object-oriented architect 
of the ASX framework, this paper describes ourexperienc 
using the ASX framework to develop commercial softwa 
for a* family of distributed system management applicatio 
at a major telecommunications company. These applicauo 
manase private-branch exchange (PBXs) switches and pc 
lie central-office telecommunication switches across hetci 
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Figure I: Class Categories in the ASX Framework 

geneous hardware and software platforms. 

This paper is organized in the following manner: Section 2 
outlines the architectural components in the ASX framework; 
Section 3 examines the object-oriented structure of a produc- 
tion distributed Call Center Management system built using 
ASX; and Secuon 4 presents concluding remarks. 

2 The Object-Oriented Architecture of 
the ASX Framework 

This section oudines the major class categories in the ASX 
framework. A class category is a collection of software 
components that collaborate to provide a set of related ser- 
vices [1]. The architecture of the ASX framework was de- 
veloped incrementally by generalizing from extensive expe- 
rience with building a range of distributed systems (includ- 
ing on-line transaction processing systems [10], telecommu- 
nication switch monitoring systems [11], and parallel com- 
munication subsystems [2]). After developing several proto- 
types and iteraung through a number of alternative designs, 
the class categories illustrated in Figure 1 were identified and 
implemented. 2 

Using ASX a distributed application may be formed by 
combining and customizing components in each of the fol- 
lowing class categories via object-oriented language features 
such as data abstraction, inheritance, dynamic binding, ob- 
ject composition, and template instantiation: 

• Stream Class Category: These components are respon- 
sible for coordinating the configuration and run-time exe- 
cution of one or more Streams [2]. A Stream is an object 



"Throughout [he paper, object -oriented component relationships are il- 
lustrated via Booch nouaon [1]. Solid clouds indicate objects: nesting indi- 
cates composition relationships between objects; and undirected edges in- 
dicate a link exists between two objects. Soiid rectangles indicate class cat- 
egories, which combine a number or related classes into a common name 
soace. 



used to configure and execute application-specific services 
tn the ASX framework. A Stream contajns a series of inter- 
connected Module objects that may be linked together stat- 
ically by developers at compile-time or dynamically by ad- 
ministrators or applications at installation-urne and at run- 
time. Modules are used to decompose the architecture of a 
distributed applicauon into functionally distinct layers. Each 
layer implements a cluster of related services (such as an end- 
to-end transport service, a presentation layer formatting ser- 
vice, or an event routing service for monitoring the behav- 
ior of telecom switches). Every Module contains a pair of 
Queue objects that are used to partition a layer into its con- 
stituent read-side and wnte-side processing functionality. 

A distributed applicauon may be implemented as an inter- 
connected series of Module objects that communicate by 
exchanging typed message objects with adjacent Modules. 
Modules may be joined together statically and/or dynami- 
cally in essentially arbitrary configurations in order to satisfy 
application requirements and enhance component reuse. 

• Service Configurator Class Category: These compo- 
nents are responsible for inserting and removing the run-time 
address bindings of services implemented by Modules in 
shared object libraries. The Service Configurator 
components provide an extensible object-oriented interface 
and a configuration scripting language that automates the use 
of OS mechanisms for explicit dynamic linking [11]. This 
enables one or more Streams to be dynamically reconfigured 
without requiring the modification, recompilauon, relinking, 
or restarting of executing applications. 

• Reactor Class Category: These components are re- 
sponsible for demultiplexing I/O-based events received on 
communication ports, time-based events generated by a 
timer-driven callout queue, or signal-based events [10]. 
When these events occur at run-time, the Reactor dis- 
patches the appropriate pre-registered handler(s) to pro- 
cess the events. The Reactor encapsulates the select, 
poll, and WaicF orMultipleObjects I/O demulti- 
plexing system calls via a portable, extensible, and type-safe 
object-oriented interface. Select and poll are UNIX sys- 
tem calls that detect the occurrence of different types of input 
and output events on one or more I/O descriptors simulta- 
neously. Wai tForMul tipleObj eccs is a Windows NT 
system call that provides similar demuluplexing functional- 
ity. 

» Concurrency Class Category: These components are 
responsible for # spawning, executing, synchronizing, and 
gracefully terminating services at run-time via one or more 
threads of control [2], In the ASX framework, services may 
be executed at run-time using several different types of pro- 
cess and thread mechanisms provided by the underlying OS. 
Bydecoupling service behavior from the type of mechanisms 
used to invoke a service, the ASX framework increases the 
range of concurrency configuration alternatives available to 
developers [2]. 
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• EPC-SAP Class Category: These components are re- 
sponsible for receiving and transmitting data with partici- 
pating communication peers residing on processes in local 
or remote hosts. The IPC.SA? components standard OS 
local and remote EPC mechanisms (such as UNIX sockets 
and Windows NT named pipes) within a type-safe object- 
oriented interface [9]. To improve service portability, the 
I?C_SA? classes may be used in conjunction with object- 
oriented language features (such as inheritance and parame- 
terized types) to minimize an application's reliance on a par- 
ticular type of IPC mechanism. 

The lines that connect the class categories in Figure 1 in- 
dicate dependency relationships. For example, components 
implementing the application-specific services in a particular 
distributed applications depend on the Stream components, 
which in turn depend on the Service Configurator 
components. Since components in the Concurrency class 
category are used throughout the application-specific and 
application-independent portions of the ASX framework, 
they are marked with the global adornment. 

The ASX framework incorporates concepts from several 
other modular communication frameworks such as the Sys- 
tem V STREAMS [12], the jr-kernel [8], and the Conduit 
framework (7] from the Choices object-oriented operating 
system. These frameworks all contain features that support 
the flexible configuration of network software via the inter- 
connection of building-block protocol and service compo- 
nents. In general, these frameworks encourage the develop- 
ment of standard communication-related components by de- 
coupling application-specific processing functionality from 
the application-independent communication framework in- 
frastructure. 

3 Implementing a Distributed System 
with the ASX Framework 

The ASX framework is being used to develop a family of dis- 
tributed system management applications that monitor and 
control PBX and central-office telecommunication switches 
in a Call Center Management (CCM) system. A CCM sys- 
tem provides a set of services that allow the staff of a call 
center (such as an airline reservation center or an insurance 
claims processing center) to assess the call center perfor- 
mance and the quality of service provided to customers. This 
section describes the behavior of the CCM system and illus- 
trates ASX framework components that were used to imple- 
ment the distributed CCM software. 

3.1 Overview of the Call Center Management 
System 

The ASX-based CCM system controls the processing of 
information that is generated continuously by system oper- 
ators, telecommunication switches, and networks. Supervi- 




Figure 2: Distributed Components in the Call Center Man- 
agement System 

sors use this informadon to interactively monitor and opti- 
mize system performance, as well as to forecast future allo- 
cation of resources (such as operators and switch capacity) 
to meet customer demands. 

Figure 2 illustrates the distributed architecture of the CCM 
system. In this system, telecommunication switches route 
incoming customer calls to an operator Operator interac- 
tions with customers are expedited by graphical user inter- 
faces on hosts that access a database of customer accoun 
records. The CCM system condnuously generates perfor- 
mance data (known as "activity events") that reports the ac- 
tivities of operators and switches. These activity events arc 
sent automatically to a central event server, which runs on \ 
separate network connected to the operator group networks 
The event server is a mediator that analyzes, filters, and for 
wards the activity events it receives to other hosts throughou 
the network. These hosts summarize the activity events the; 
receive, and display them to supervisors in a concise, graph 
ical formati 

The object-oriented design and implementation of th- 
CCM system is strongly influenced by requirements for plat 
form independence and configuration flexibility. Platforr. 
independence is necessary since the CCM system is largete 
for various configurations of telecommunication switche 
(such as PBX and central-office switches), host platforrr 
(such as Windows NT. Windows 3.1, OS/2, and UNIX), an 
wide-area and local-area networks (such as X.25, TCP/I 
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and Novell IPX/SPX). Configuration flexibility is necessary 
Since not ail call center installation sites require every feature 
provided by the CCM system. It would be possible (although 
highly undesirable) to manually construct and deliver one or 
more CCM systems that are customized for the platforms and 
the subsets of features required by a particular site. How- 
ever, such a static configuration process would require that 
Lhe selection of services and the division of labor between 
different hosis in a distributed CCM system be completely 
fixed during initial system deployment. Our experience with 
earlier-generation CCM systems indicated that even if this 
information was available at the time of deployment, it was 
likely to change in the future, often upon short notice. 

The ASX framework facilitates both platform indepen- 
dence and configuration flexibility to improve software com- 
ponent reuse across platforms and to reduce development ef- 
fort. For example, C++ abstract base classes, inheritance, dy- 
namic binding, and parameterized types are used extensively 
throughout the CCM system to localize and minimize plat- 
form dependencies. Likewise, the ASX framework is used 
to defer the point of time at which a particular set of services 
are configured toother to form a CCM application. By com- 
bining advanced OS features (such as mulu- threading and 
explicit dynamic linking) and C++ language features (such 
as templates, inheritance, and dynamic binding), the ASX 
framework enables services offered by CCM applicauons to 
be extended without modifying, recompiling, relinking, or 
even restarting the system at run-time [11). 

3.2 Mapping CCM Functionality onto ASX 
Components 

Figure 3 illustrates the ASX framework components used 
to implement the event server portion of the CCM system 
(the other components in the CCM system are not desenbed 
in this paper). The event server performs the following tasks: 

♦ It receives activity events generated continuously by op- 
erator hosts and telecom switches 

. It analyzes and filters the activity events it receives to 
determine which actions to perform and which supervi- 
sors should receive which incoming activity events 

♦ It forwards the filtered activity events across a network 
to the subset of supervisor hosts that have previously 
registered to receive these events 

The CCM event server is composed of four hierarchically- 
related Modules that may be configured statically and/or 
dvnarrucallv by the run-time environment available in the 
ASX framework. The use of ASX Modules helps to 
jm prove the platform independence of the CCM system 
bv encaosulating non-portable system mechanisms (such 
as communication protocols and activity event frame for- 
mats) behind abstract interfaces. This section describes the 
behavior of the Swicch^dapter. Event-Analyzer, 
SvencJilter. and Session-Router Module objects 
that comprise the CCM event server. 




Figure 3: ASX Components in a Distributed Call Center 
Manager 

3.2,1 The Switch_Adapter Module 

The Switch-Adapter Module object coordinates com- 
munication with telecom switches monitored by the CCM 
event server. This Module shields the higher layers of the 
event server architecture from switch-specific communica- 
tion charactenstics (such as activity event frame formats) 
The Switch-Adapter Module maintains a collection of 
Switch-IO objects that are responsible for parsing incom- 
ing acu vity events. These activity events are transformed and 
encapsulated into a canonical switch-independent message 
object which is built atop a flexible message management 
class desenbed in [2). After being allocated and initialized, 
the incoming canonical message objects are passed upstream 
to the Event-Analyzer Module. 

3.2.2 The Event_Analyzer Module 

The Event-Analyzer Module is used to transform 
switch-specific activity events into a switch-independent for- 
mat. This transformauon process helps to improve system 
portability. For instance, only the Event-Analyzer por- 
tion of che eve'nt server was affected significantly when the 
original PBX-based version of the CCM system was ported 
to a different central-office switch architecture. Dunng the 
event analvsis process, the Svent_Analyzer also synthe- 
sizes switch-independent derived events that are triggered ort 
the occurrence of one or more switch-specific events. After 
the Event-Analyzer has transformed and/or synthesized 
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incoming activity events, it forwards the new events to the 
Event-Filter Module. 

3.2.3 The EventJFilter Module 

The Event -Pi leer Module minimizes unnecessary net- 
work traffic by forwarding only those activity events 
that at least one supervisor has registered to receive. 
The Event-Filter contains a collection of Event 
Forwarding Discriminator (EFD) objects. An EFD 
object contains a predicate that indicates the rype of activ- 
ity event(s) a supervisor wants to receive. An EFD predi- 
cate may be used to selectively filter out activity events based 
on criteria such as event rype, event value, event generation 
time, and event frequency. An EFD predicate may contain 
relational operators that allow the composition of arbitrarily 
complex filter expressions. 

During system configuration, supervisors may register 
EFD objects with the event server. During system execution, 
the event server inspects the registered EFDs to determine 
the set of supervisors that should receive each incoming ac- 
tivity event If an activity event matches a supervisor's EFD 
predicate, the supervisor's addressing information is added 
to the Session_Sec in the message object that encapsu- 
lates the activity evenL After all the EFDs are inspected by 
the Event-filter Module, the message object contain- 
ing the activity event and the Session-Set is passed up- 
stream to the Session_Houter Module. 

3.2.4 The Session_Router Module 

The Session-Router Module is a reusable ASX com- 
ponent. It shields the lower layers of the CCM event server 
from non-portable details of the communication protocols 
used to communicate with supervisors. Supervisors con- 
nect to the event server by establishing a session with the 
Session-Router Module. A separate Session_IO 
object is created to manage each supervisor session. This 
SessioruIO object handles aJl the data transfer and con- 
trol operations between the event server and a supervisor. 
After connecting to the event server, a supervisor indicates 
the rype of activity event(s) he or she would tike to moni- 
tor. Subsequently, when the Sess ion_Router receives a 
message object from the Event-Filter Module, it auto- 
matically multicasts the message to all the supervisors indi- 
cated by the addressing information residing in the message 
object's Session-Set. 

The Service.Conf ig object illustrated in the middle 
of Figure 3 is a reusable component from the ASX frame- 
work's Service Configurator class category [11]. 
The event server uses this object to control the initial con- 
figuration, subsequent reconfiguration(s), and termination of 
Modules from the Stream class category. Modules 
may be configured statically at installation- time or recon- 
figured dynamically at run-time. The Service.Conf ig 
object integrates other ASX framework components such 
as the Ser/iceJ^epository and the Reactor. The 



Service-Repository is an object manager that sim- 
plifies the run-time configuration and administration of the 
Modules used to implement protocol stacks in a Stream. 
The Reactor is an event demultiplexer that dispatches in- 
coming messages from supervisors and activity events from 
switches to the appropriate SessioruIO and Switch.IO 
event handlers, respectively. Messages arriving from super- 
visors are received by a Session_IO object, sent down- 
stream through the CCM-Stream object, and handled by the 
appropriate Module (e.g., EFD registrations are handled b> 
the Event-Filter Module). Likewise, incoming eventf 
from switches are received by a Swi tch_IO object and sen 
upstream starting at the Switch-Adapter Module. 

33 CCM Event Server Configuration 

The Modules that comprise the CCM-Stream object ma) 
be configured into the event server at installation-ume by de- 
velopers, as well as at run-time by system administrators o 
by applications. The ASX framework provides this degree o 
flexibility by combining OS explicit dynamic linking mech- 
anisms with a configuration scripting language (described ii 
[11). For example, the Service Configurator clas: 
category uses following configuration script to determine 
which services to dynamically link into the address space o 
the event server at installation-time: 

scream CCM_Stream dynamic 

STREAM * / svcs/CCM_StreaJTi . so : al loc ( ) { 
dynamic Swi cch_Adapcer 

Module • /svcs/SA . so : alloc ( > * -p 2001' 
dynamic Even L_ An a lyrer 

Module * /svcs/EA . so : alloc ( ) 
dynamic EventJFilter 

'Module * / svcs/'EF . so : al loc ( ) 
dynamic Sess ion_Rou ter 

Module * /svcs/SR . so: alloc ( ) * -p 2010' 

) 

The configuration script shown above indicates the ordc 
in which the four Modules in the CCM event serve 
are dynamically linked and pushed onto the CCM-Strea: 
object. During the installation of the event server, th 
ServiceXonfig class parses this configuration scri| 
and carries out the directives described by each entry, as fo 
lows: 

1. The dynamic directive instructs the ASX framewoi 
to dynamically link the shared object file (specified k 
a pathname ending in . so) into the address space of ti 
CCM event server 

2. The framework the extracts and invokes the dynar 
ically linked alloc function, which allocates an i; 
stance of the specified Module object from the shar< 
object library 

3. The framework then invokes the ini t methods on tl 
two Queues in the Module, passing in any initializ 
tion parameters (which may appear as string literals 
the end of the line) 
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4, At this pome, the framework enters an event loop that 
waits tor control messages to amve from supervisors or 
for activity events to amve from switches and/or oper- 
ator hosts 

When events arrive at run-time, the Reactor automatically 
dispatches the appropriate methods of the Switch-IO and 
Session_IO objects to initiate Stream processing. 

3.4 CCM Event Server Reconfiguration 

This section motivates and illustrates the dynamic reconfig- 
uration mechanisms provided by the ASX framework. A ma- 
jor objective of the CCM project was to allow developers to 
decide very late in the development cycle (i.e., at mstailation- 
time or run-time) which services would run in supervisor 
hosts and which would run in the event server. Our expe- 
rience with earlier versions of the CCM system indicated 
that it was difficult to determine the appropnate mapping of 
services onto hosts a priori since processing characteristics, 
workloads, and OS/hardware platforms vary over time. 

The run-time control environment provided by the ASX 
framework is used to support the CCM flexible reconfigu- 
ration requirements. This flexibility proved to be quite use- 
ful for the CCM project since different OS/hardware plat- 
forms and different network characteristics required differ- 
ent service configurations. For example, in some environ- 
ments the event server performed most of the work since it 
ran on a multi-processor platform, whereas the supervisor 
hosts were inexpensive PCs attached to the event server via 
low-bandwidth networks. Conversely, in otherenvironments 
the supervisor hosts performed most of the work since these 
hosts were powerful workstations connected to a high-speed 
network. 

The CCM_Stream shown in Figure 3 performs all event 
analysis and event filtering processing directly in the event 
server. However, this configuration may not be appropriate 
for certain CCM environments. For example, performance 
may be degraded if supervisors configure a large number of 
Event Forwarding Discriminator (EFD) objects into an event 
server. In this case, the centralized event server may be- 
come a bottleneck and performance would suffer, even if 
there were surplus processing capacity available in the net- 
work and in the supervisor hosts. Figure 4 illustrates how the 
configuration shown in Figure 3 may be modified to operate 
efficiently in a distributed environment where event server 
processing constitutes the primary performance bottleneck. 

The following senpt may be used to dynamically recon- 
figure Modules in the CCM system: 

suspend CCM_S cream 
scream CCM_Scream ( 
remove H^enc_7il ter 

) 

remoce ' -h all -p 911* ( 
scream CCM_Stream { 
dynamic Evenc_ Fi leer 

Module * /sves /EF . so : alloc ( ) 




Figure 4: Reconfiguration of the Call Center Manager 

) 

resume CCM_S tream 

This new script transfers the event filtering functionality 
from the event server to the supervisor hosts using the fol- 
lowing steps: 

1. It suspends the event server's CCM-S tream object 

2. It removes the Event-Filter Module from the 
COLStream and dynamically unlinks the associated 
shared object library 

3. It then dynamically links the Evenc-Fi i ter Module 
into Streams on all the supervisor hosts 

4. Finally, it resumes the event server's CCM-Stream ob- 
ject 

As a result of this reconfiguration, the overhead of event fil- 
tering is distributed among all the supervisor hosts, rather 
than being centralized at the event server. 

We are currendy evaluating the performance of the CCM 
distributed architecture depicted in Figures 3 and 4 to deter- 
mine how to* parallelize the CCM event server more effec- 
tively. Using the ASX framework, it is straightforward to 
reconfigure the binding of threads onto Modules or mes- 
sages in order to reduce programming effort and improve 
performance [2). We are also investigating service migra- 
tion policies to formulate guidelines that ensure the dynamic 
reconfiguration of the event server does not disrupt or cor- 
rupt active services. A more ambitious long-term project 
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involves using the ASX reconfiguration mechanisms to ex- 
periment with service migration policies that relocate certain 
services dynamically to reduce overall system workload at 
run-lime. 

4 Concluding Remarks 

The ASX framework provides an object-oriented infrastruc- 
ture that supports static and/or dynamic configuration of net- 
work services that execute within one or more OS processes 
and threads. The object-oriented design principles underly- 
ing the ASX framework separate policies from mechanisms 
via object-oriented language features (such as abstract base 
classes, inheritance, dynamic binding, and parameterized 
types). This separation of concerns enhances the reuse of 
common distributed application software components. Com- 
ponent reuse is also facilitated in the ASX framework by de- 
coupling the higher-level application-specific policies (such 
as acuvity event filtering) from the lower-level application- 
independent mechanisms (such as the choice of mechanisms 
for network communication, event demultiplexing and ser- 
vice dispatching, and process/ thread execution agents). 

in addition, the ASX framework helps to decouple 
application-specific service functionality from the binding 
onto OS processes and threads in order to improve flexi- 
bility and performance. Explicit dynamic linking and dy- 
namic binding arc also utilized to help improve extensibility 
and permit fine-grained ume/space tradeoffs. Together, the 
object-oriented design principles and OS/language features 
facilitate the development of network services that may be 
updated and extended without modifying, recompiling, re- 
linking, or restarting existing applications at run-ume (11). 

The ASX framework described in this paper has been used 
in a production environment to simplify the configuration, 
installation, and administration of a family of distributed 
system management applications for a major telecommuni- 
cations company. By using the ASX framework, develop- 
ers have been able to enhance distributed application func- 
tionality and reliability, as well as fine-tune system perfor- 
mance, without extensive redevelopment and re-installation 
effort. For example, debugging a faulty service typically in- 
volves dynamically reinstalling a functionally equivalent ser- 
vice containing additional instrumentation that helps to iso- 
late the source of the erroneous behavior. 

Thus far. the primary obstacles encountered by using 
object-oriented techniques and C++ have been primarily 
managerial and tool-related, rather than technical problems. 
For example, it is difficult to find experienced systems ana- 
lysts, designers, and programmers who are intimately famil- 
iar with applying C++ and object-oriented design methods in 
distributed communication system environments. Further- 
more, the level of maturity of many C++ compilers and lan- 
guage processing tools has been inadequate on UNIX, Win- 
dows NT. and OS/2 plarforms. For example, many C-m- de- 
buggers do not support multi-threading correctly and many 
C++ compilers implement only a subset or the language. 



Over time, it is iikeiy th3t the tooi-related concerns will be- 
come less problematic, particularly once the ISO/ ANSI C-m- 
standard is adopted. However, for the interim period, it is 
essential to staff complex software projects carefully to min- 
imize development risks. For the COM project, we found it 
useful to hire a small number of experienced OOD/C++- ex- 
perts, who have worked closely with less experienced devel- 
opers to shepard them through the object-oriented learning 
curve. 

Components in the .ASX framework are being used in 
a number of large-scale distributed systems including the 
AT&T Q.pon ATM signaling software product, the network 
management portion of the Motorola IRIDIUM global per- 
sonal communications system, and a family of telecommu- 
nication switch management systems developed at Erics- 
son/GE mobile communications. Public domain versions 
of the ASX framework described in this paper is avail- 
able via anonymous ftp from ics.uci.edu in the file 
gnu /C + + .wrapper s . car . Z. 



References 

[lj G. Booch, Object Oriented Analysis and Design with Ap- 
plications (2 Edition). Redwood City, California: Ben- 
jarrun/Cummings, 1993. 

[21 D. C. Schmidt and T. Suda. "Measuring the Impact of Alter- 
native Parallel Process Architectures on Communication Sub- 
system Performance," in Proceedings of the 4 ,rt International 
Workshop on Protocols for High-Speed Networks, (Vancou- 
ver. British Columbia). I HP. August 1994. 

[3] R. Johnson and B. Foote. "Designing Reusable Classes." 
Journal of Object-Oriented' Programming, vol. 1. pp. 22-35, 
June/July 1988. 

[4] M. A. Linton and P. R. Calder. "The Design and Implemen- 
tation of Interviews." in USENIX C-r + Workshop November. 
November 1987. 

[5] D. Batorv and S. W. O'Malley. "The Design and Implementa- 
tion of Hierarchical Software Systems Using Reusable Com- 
ponents/" ACM Transactions on Software Engineering and 
Methodology, vol. I. Oct. 1991. 

(6] R. Campbell. V. Russo. and G. Johnson. The Design of a 
Multiprocessor Operating Svstem." in USENIX C++ Con- 
ference Proceedings, Dp. 109-126. USENIX Association. 
November 1987. 

[71 J. M. Zweig. "The Conduit: a Communication Abstraction 
in C++." in USENIX C++ Conference Proceedings, pp. 191- 
203. USENIX Association. April 1990. 

(8J N. C Hutchinson and L. L. Peterson. "The x-kernel: An 
Architecture for Implementing Network Protocols." IEEE 
Transactions on Software Engineering, vol. 17, pp. 64—76. 
January 1991. 

(91 D. C. Schmidt, "IPCSAP: An Object-Oriented Interface to 
Interprocess Communication Services." C+ + Report, vol. 4. 
November/December 1992. 

(10] D. C. Schmidt. 'Reactor: An Object Behavioral Pattern for 
Concurrent Event Demultiplexing and Dispatching." in I " 
Annual Conference on the Pattern Languages of Programs. 
(Monticello! Illinois). ACM. August 1994. 

(11) D. C. Schmidt and T. Suda, "The Service Configurator Frame- 
work: An Extensible Architecture for Dynarrucaily Config- 
uring Concurrent. Mulu-Service Network Daemons." in The 
Proceedings of the Second International Workshop on Con- 
figurable Distributed Svstems. (Pittsburgh. PA), pp. 190-201, 
IEEE. Mar. 1994. 

(12) D. Ritchie. "A Stream Input-Output System." AT&T Bell 
Labs Technical Journal, vol 63. pp. 31 1-324. Oct. 1984. 



506 

: <XP 488600A_J_> 



THIS PAGE BLANK (uspto) 



s 



